从一个enq TM问题的分析方法谈起

很多年轻的DBA总是羡慕老法师总是能够在复杂的问题现场中很快的抓到问题的关键，准确的定位问题解决问题。而到了自己的头上，总是像段誉刚刚学会六脉神剑一样，灵感忽有忽无。实际上这是知识积累的深度与厚度的差异导致的，老法师们经历过大量的实战案例，积累了丰富的运维经验，同时通过不断的学习掌握了足够的原理与技能方面的知识。因此在他们的脑子里已经构建出了一个十分庞大的知识图谱，因此能够面对任何问题的时候都游刃有余。而你则是因为知识与案例积累不够，学过的知识都是点状的，无法构成四通八达的图谱，因此总是在分析问题的时候卡住。

帮DBA朋友们更加快速的构建运维知识突破，打通脑子里的任督二脉是我一直在做的事情，2010年左右编写的《DBA的思想天空》就是希望通过对Oracle基本原理的理解，实现原理与实战融合的目的。有不少DBA朋友第一次线下见到我的时候总是说我是看着这本书开始学习DBA的技能的，这总会让我很高兴，自己的思想能够给别人帮助，是最令人高兴的。

以这个enq: TM - contention 的问题为例，我们今天来聊一聊DBA如何利用运维知识来解决问题。当我看到这个问题的时候，首先想到的什么是TM锁。enq: TM的含义是DML (Table Manipulation) Enqueue，当一个表在被DML修改的时候产生的锁。从这个问题首先可以确定，这个锁一定是和DML语句有关的，DML语句需要获得共享的TM锁，从而保护语句的执行。一般情况下在系统中很少看到比较严重的enq: TM – contention等待，比较常见的出现这种严重等待的场景是：1）DML语句的执行效率很低，常见的原因是当DML影响的数据存在外键，而子表上的外键关联字段上缺乏索引，那么这个DML语句将会执行得很慢，TM冲突也就会比较严重；2）有人使用LOCK TABLE锁住了某张表。

其中第一个原因比较常见，因此我首先想到了这个问题。那么下一步该如何定位分析呢？如果你手头有AWR报告，那么就可以直接去查看TOP SQL中是否存在某条执行得比较慢的DML语句，一般情况下，在buffer gets比较多的语句里比较容易查到。    

很幸运我们一下子就看到了一条INSERT和一条UPDATE。这两条语句修改的是同一张表，每次的Gets都很高，高达12800+。通过查看语句详情，发现insert/update都是普通的单条写入和修改操作。一般情况下，Gets数量也就是几个而已。至此问题基本定位，所花的时间基本上相当于打开AWR报告文件再加上一两分钟而已。

如果我们在现场，没有做AWR报告，其实也很容易分析，直接通过v$session查看enq: TM – contention等待的会话执行的SQL情况就可以了。也很快可以定位到问题所在。

如果我们目前对这个知识点的了解还不够，那么我们可以直接到MOS上去搜索，查找我们所需要的答案。    

我们可以很快看到Steps to Address enq: TM - contention Waits when Parent and child relationed tables exists (Doc ID 2953778.1)这篇文章，仔细阅读一下这篇文章，根据指引也很快就能找到答案了。    

有时候我们无法在线访问MOS，那么构建自己的离线知识库就十分重要了。我从二十年前就利用scrapbook来保存我阅读过的MOS文章，scrapbook无法使用后，我目前暂时使用Scrapbee来继续管理这个离线知识库。

实际上如果无法用上面的方法找到答案，我们还可以借助谷歌，百度等搜索引擎，一些常见问题还是能找到靠谱的答案的。使用CHATGPT、NEWBING等大模型工具是现在的一个新方法。    

Newbing的靠谱指数远超谷歌百度等传统的搜索引擎，因此建议DBA朋友们可以尝试一下。对于有条件建立自己的离线知识库的朋友，也可以利用大模型技术去构建自己的离线大模型。花上几千块钱，买块二手的3090或者3060显卡，利用一些参数不是很大的开源大模型，利用像DB-GPT这样的开源项目搭建一个自己的知识库，也是完全可行的。